NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/std/c/43

Text File | 1996-08-06 | 3.6 KB | 106 lines

Path: mail2news.demon.co.uk!genesis.demon.co.uk
From: Lawrence Kirby <[e-mail]>
Newsgroups: comp.std.c
Subject: Re: Undefined result vs. int's holding undefined values.
Date: Sat, 06 Jan 96 17:59:00 GMT
Organization: none
Message-ID: <[e-mail]>
References: <4ck70b$[e-mail]> <4ckms5$[e-mail]>
Reply-To: [e-mail]
X-NNTP-Posting-Host: genesis.demon.co.uk
X-Newsreader: Demon Internet Simple News v1.27
X-Mail2News-Path: genesis.demon.co.uk

In article <4ckms5$[e-mail]>
           [e-mail] "Daniel Wood" writes:

>Someone has pointed out(Besides my return address being wrong) that the
>correct term in the following is "undefined behavior" not "undefined result"
>and that the behavior stems from trying to store the value in the object.

No, the undefined behaviour stems from the calculation of the value. If f
were simply defined as:

void f(int x, int y)
{
    x-y;
}

it would still result in undefined behaviour.

>One of the undefined behaviors could be to core dump.

True, and that might happen as a result of an arithmetic overflow exception,
but doesn't have to.

>That still avoids the question of once we have stored something into "r"
>below and the program has NOT core dumped whether it is then acceptable for
>everything >and anything after that to exhibit undefine behavior beyond the
>act of storing the value.

Once you have invoked undefined behaviour you can say nothing about the
behaviour of the program from that point on.

>ORIGINAL MESSAGE FOLLOWS:
>
>THE TEST CASE, on SCO:

'SCO' is a little woolly here. You could be using (Microsoft based) cc,
(SVR4 based) cc, rcc, icc or gcc. I managed to get the behaviour you describe
with icc. The assembler listing is interesting but not really relevant to
comp.std.c (in the first case it does a test based on the subtraction, in
the second case the value of the result is tested. Where the subtraction
is valid these will have the same effect).

>main() { f(-2147483647, 1879048192); }
>
>f(int x, int y) {
>        int r;
>
>        if ((r=(x-y)) > 0)
>                printf("1: r greater than 0\n");
>
>        if (r > 0)
>                printf("2: r greater than 0\n");
>}
>
>On SCO only the second print occurs.  The reason given to me is that ANSI
>states
>that the result of an overflowing/underflowing operation is undefined.  The
>implementation is free to do what it wants with the result.

It is the behaviour that is undefined, not the result (well, if you get a
result that will be undefined too).

> This is fine
>with me, however int's, unlike floats, have NO undefined bit patterns

Not true (at least not for signed integer types) - i.e. the standard
doesn't prohibit undefined bit patterns.

>and
>no matter what you do with the undefined result(Scramble the bits for all
>I care) once you store that something into an int variable that int
>is NOT undefined and allowed to exhibit volatile behavior.

It is once undefined behaviour has occurred in the program.

>Saying a result is undefined "IS NOT EQUAL TO" saying that a C int variable
>can actually hold an undefined value.

A conforming implementation might detect some forms of undefined behaviour
in a program and set a flag which causes random numbers to be applied to all
subsequent operations.

> If you think the test case is running
>acceptably, as described above, then tell me the section of the standard that
>states or implies that an int variable can hold an undefined value.

Not relevant.

--
-----------------------------------------
Lawrence Kirby | [e-mail]
Wilts, England | [e-mail]
-----------------------------------------